Subject: Response to last minute editorial changes to DLSw CP version

From: "Alan K. Bartky, Manager of Technology" <[email-masked]>
Date: Mon, 16 Jan 95 12:18:55 PST

Fellow Data Link Switchers-

This email is to respond to the four posted last minute editorial
changes to the Data Link Switching Closed Pages version.  Most were
minor editorial suggestions and none of them that I accepted
change any technical content.

Edits have been incorporated into my master document as indicated
in my comments listed with an AKB> below.

As soon as the chair (Louise) decrees consensus approval for Closed Pages
status, I will post the document on the IBM FTP server.

Regards,

Alan (your happy to be almost finished :-) editor )

***********************
Begin inclusion
*********************** 

***********************
>From Peter Gayek IBM
***********************

The IBM team has reviewed 016 and we support granting it CP status.
The following are a few minor comments from our review which Alan
may wish to incorporate in his final edit, but only if this doesn't
delay the process of finishing up.

- Section 6.1, Flow #1 (first of the three parts)
  Steve Klein pointed we are missing a DLC_RESOLVE_R flowing right
  to left immediately after the ICANREACH_ex.  This is just fixing
  the example to match the state machine, which is correct.
- Section 6.1, Flow #1 (second of the three parts)
  Again, need a DLC_RESOLVE_R flowing right to left between the
  TEST_rsp and ICANREACH_ex.

AKB> CHANGED ALL FLOWS with ICANREACH_ex to Add DLC_RESOLVE_R

- Section 7.5.7, 2nd paragraph (just changed)
  I think the terminology we all agreed to was "TCP connection", not
  "TCP circuit".  The latter may confuse people since everywhere else
  we are consistent.

AKB> Done.

- Section 8.6, the Note (just changed)
  Delete "following" from "... may be piggy-backed on any of the
  following message types listed in section 8.2."

AKB> Done.

- References, #2
  The publication cited is now obsolete.  The same NetBIOS info
  is now in "IBM LAN Technical Reference:  IEEE 802.2 and NETBIOS
  Application Program Interfaces", SC30-3587.  The -00 revision level
  was published in December 1993.

AKB> Done

Peter Gayek
IBM Corporation

**********************
>From Paul Brittain DCL
**********************

Louise, Alan et al:

This email represents concensus to revision 0.16 for Closed Pages from Data 
Connection.  Well done all round - and special thanks to Alan for all his 
hard work.

There are a number of typos or clarifications that we have spotted in the CP 
document as described below.  However our concensus to CP for 0.16 is _NOT_ 
conditional on any of these minor corrections.

Paul Brittain
Data Connection

MINOR CORRECTIONS TO 0.16
=========================

All page numbers/corrections listed below are based on the TEXT version of 
0.16.

Section 2, Page 6:
==================

Paragraph 5, line 2 - delete the extra space between 'connection' and 
'-oriented'

AKB> Done.

Section 3, Page 8:
==================

Last paragraph, last line - delete the extra space between 'source-' and 
'routed'

AKB> Done

Section 3.5, Page 20:
=====================

Last paragraph of section - remove the first sentence starting 'Any SSP 
message types not defined above ...' as it is a less clear version of the 
rest of this paragraph.

AKB> Don't agree, text stays as is.  We had several discussions on this and I don't want to 
change it again.

Section 5.1, Page 23:
=====================

First paragraph of section, second sentence - replace 'eleven possible 
states' with 'thirteen possible states' (!)

AKB> Done

Section 5.2.1, Page 30:
=======================

Second last paragraph of section - correct the sentence:

"The DISCONNECTED state is exited upon the sending of receipt of a 
CANUREACH_cs message by a prospective target Data Link Switch"

by replacing it with:

"The DISCONNECTED state is exited upon the sending of a CANUREACH_cs by the 
origin DLSw or the receipt of a CANUREACH_cs message by a prospective target 
Data Link Switch."

This change brings the text in line with the state table.

AKB> Agree, Done.

The following sentence should read "In the later case..." not " In the 
former case...".

AKB> Agree, Done.

The note following this paragraph should be moved to the end of section 
5.2.3 as it applies to the ICR case not CUR.

AKB> After checking the note, and your suggestion, I have decided to remove it entirely.
I am assuming this was a note put in by the original authors of RFC 1434 in order to 
explain what may happen.  Since we have gone to a philosphy of splitting the Data Link
establishment into two phases of the state machine, this note only adds confustion and
probably only related to the 6611 implementation prior to the version 1.0 state machine
changes.

Section 5.2.3, Page 32:
=======================

The existing note at the end of this paragraph is confusing and should be 
removed - the paragraph above it explains things perfectly adequately.

AKB> Agree, Done.

Chapter 7, page 64:
===================

An short additional section between 7.2 and 7.3 on the use of the Initial 
Capex would make the flow clearer for people who are not familiar with our 
RIG discussions.  Please consider adding the following:

7.3  Initial Capabilities Exchange

Capabilities exchange is always the first SSP message sent on a new SSP 
connection between two DLSw switches.  This initial Capabilities Exchange is 
used to identify the DLSw version that each switch is running and other 
required information, plus details of any optional extensions that the 
switches are capable of supporting.

If a DLSw receives an initial capabilities message that is incorrectly 
formatted or contains invalid or unsupported data that prevents correct 
interoperation with the partner DLSw, it should issue a Capabilities 
Exchange negative response.

If a DLSw receives a negative response to its initial capabilities message, 
it should take down its TCP connections with the offended partner.

Note:  Pre v1.0 DLSw implementations do not send or respond to capabilities 
messages and can be identified by the lack of capabilities exchange as the 
first message on a new SSP connnection.  This document does not attempt to 
specify how to interoperate with back-level DLSw implementations.

AKB> Agree, Done.

Section 7.5, page 65:
=====================

The first and second sentences convey the same information, but the first is 
clearer.  Delete the second sentence of this section.

AKB> Agree, Done

Section 7.5.3, Page 67:
=======================

Add the following clarification (c.f. section 8.5) to the end of this 
section:

Note:  The pacing window size must be non-zero.

AKB> Agree, Done

Section 8.9.1, Page 91:
=======================

Add an additional protocol violation:

5.   Receiver attempts to increment the window size beyond 0xFFFF.

AKB> Agree, Done.

************************
>From David McDonnel, DEC
************************

Louise, Alan, et al:

__X__   Digital Equipment Corporation believes that the proposed document 
posted on December 23, Editor's Version 0.16 (proposed CP document), should 
be approved for CP status.

We furthermore offer the following few minor editorial comments for possible 
inclusion into the final document -- however our vote is NOT contingent on the 
inclusion. (Page/paragraph references are to 016 *Postscript* version.)

	- section 2 (Overview), second paragraph p.5: to the novice reader
	it isn't apparent whether the LLC2-over-WAN bridging timeout behavior
	described is a shortcoming of standard tunnelling/bridging or a 
	characteristic of DLSw (although it becomes more clear in the
	paragraph that follows).  Suggested tweak: change the 3rd sentence
	of the (2nd) paragraph to read "When *conventional* bridging is used
	over wide area lines..."

AKB> Changed "bridging" to "remote bridging" to make it clear as opposed to
local (LAN to LAN) bridging which LLC works just fine.  I don't like
"conventional" as it creates the question, what is "unconventional" bridging?

	- same section, bottom p.6, last sentence begins "For circuit
	establishment,...".  Should qualify the (first use of) term "circuit" 
	w/ the DLSw definition.  (End-to-end association of DLC entities,
	identified by SA, SSAP, DA, DSAP or circuit IDs w/ node IDs, etc.)

AKB> Changed all occurances of "circuit establishment" for SNA or NETBIOS to
"LLC type 2 connection establishment".  Other occurances of "circuit
establishment" only apply to DLSw circuits.

	- section 3.5 (Message Types), top p.17: the statement "values not 
	listed are reserved...for future use" is confusing.  Are we simply
	reserving the right to augment this list in the future?  It almost
	reads like there are listed commands without values (??).

AKB> Reserved means reserved for whatever puposes, Text left as is.

	- more terminology nit-picking: first sentence in section 5 (top of
	page 21) references (for the first time, I think) "...a single
	*connection*...through the Data Link Switch."  If you mean 
	"connection", then (first reference) define it -- although I think 
	this should actually read "...describe the states for a single
	circuit over a transport connection...", no?

AKB> "connection" changed to "circuit"

	- general comment: I know this has come up before, but the document
	is LLC2-centric (over SDLC) in that there remain many references to
	SABME without regard to	SNRM/E (e.g. DLC_CONTACTED is defined as the
	"receipt of a SABME...".  Maybe a qualifying footnote on the first 
	mention of SABME (or the substituion of the "DLC mode-setting command"
	generalization) is in order.

AKB> Several problems with this.  One is that we have been over this issue
before and have had consensus approval to leave the document in LAN-centric
form as it would be too much work to make it more generic.  Two is that
section one clearly states that SDLC appears as a MAC/SAP internally.
Third is that we have talked at the meeting about how the end-system LLC
or SDLC startup part of the link is up to the implementor to handle the local data link
states.  I don't have time to change this instance of SABME to "qualify it"
and see how it fits into the rest of the document.  Text stays as is.

startup phase

	- general comment (most likely for the future): we feel that a better
	coupling between the main and two explorer FSMs would vastly improve
	the clarity of the document.  (Ideally something akin to the 
	cross-references of, for example, the CP.CS FSMs the IBM APPN FAPL
	(node reference) document.)

AKB> This is definetly for Version 2.  No change to the text.
 Please pursue these changes in the aiw-connect working group.

David McD

**************************************************************************
David McDonell                          email: [email-masked]
Networks Engineering, LKG1-3/A10                   telephone: 508 486 7126
Digital Equipment Corporation                            fax: 508 486 7438
550 King Street
Littleton, MA 01460
**************************************************************************

********************
>From Felix Lin, 3com
********************

This email represents concensus to revision 0.16 for Closed Pages from 3COM.

Following is a minor clarification that we have spotted. However our concensus
 to CP for 0.16 is not conditioned on its correction.

Felix Lin
3COM

Section 7. Page 57
------------------

2nd paragraph, since we are talking about Capabiliies Exchange Request here
(only Capabiliies Exchange Request has multiple type "LT" fields), the phrase
"Capabiliies Exchange" probably should be changed to "Capabiliies Exchange Request".

AKB> This is the only text that specifically states that multiple LT fields are allowed,
other text just refers to multiple fields.  The text for the Response message is clear
that only one LT field is allowed.  Rather than rework all the text, I am deciding to
leave the existing text as is.
    
***********************
End inclusion
***********************